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Relationship  between  IDL  and 
Structure  Editor  Generation  Technology 

P«ter  H.  F«Rer 


Abstract.  This  paper  discusses  observed  oorttmonalhies  arKi  differences  between  tOL  arKf 
structure  editor  generation  technologies.  lOL  (Interface  Description  Language)  is  technology  for 
generation  of  tool  intercommunication  support  with  roots  in  compiler  generation.  Structure  editor 
generation  technology  has  its  roots  in  syntax-directed  editors.  It  produces  environments  for  inter¬ 
active  viewing  and  manipuiation  of  formaily  specified  structures.  Both  technologies  use  a  formal 
notation  for  structural  and  constraint  descriptions.  From  these  descriptions  both  generation  tools 
automatically  produce  software  for  reading,  writing,  and  manipulating  instmces  of  the  described 
structures,  as  wen  as  for  checking  spedfied  constraints  on  information  contained  in  the  structures. 
The  lOL  technology  emphasizes  generation  of  batch-oriented  applicattons  while  the  structure 
editor  generation  technology  is  tailored  to  supporting  interactive  applications.  Structure  editor 
generation  technology  has  been  applied  to  itself,  i.e.,  to  building  an  interactive  structure  editor 
generation  environment. 


1 1ntroduction 

The  intent  of  this  artide  is  to  share  with  the  reader  some  observations  about  the  relationship  of 
IDL  (interface  Description  Language)  technology  and  structure  editor  generation  technology.  The 
origins  of  the  two  technologies  vary,  and  each  of  them  addresses  a  different  problem  domain. 
IDL  technology  has  its  roots  in  compiler  technology  and  provides  support  for  tool  intercommunica' 
tion.  Structure  editor  generation  technology  provides  a  shell  for  interactive  applications  that 
manipulate  stmdures.  In  both  cases,  the  construction  of  applications  that  manipulate  stnjctures 
is  supported  through  a  generation  approadr.  The  characteristics  of  the  structures  are  descrtred  in 
a  high-level  notation.  Both  technologies  have  chosen  similar  notations  for  the  descriptions.  From 
such  a  description  code  is  generated  for  inclusion  in  an  application.  The  differences  in  the  ap¬ 
plication  domains  are  reflected  in  the  functionality  of  the  code  being  supplied  to  the  application. 

For  the  discussion  in  this  article  we  have  chosen  the  Dose  stnjdure  edttor  generation  environ¬ 
ment  and  its  Representation  Description  Language  RDL[10]  as  a  representative  of  structure 
editor  generation  technology.  We  first  give  a  short  history  of  both  technologies.  Then,  the  ar¬ 
chitectures  implied  for  the  applications  are  compared.  This  is  followed  by  a  discussion  of  the 
structural  description  facilities,  the  support  for  composing  and  viewing  stnjctures,  and  the  notation 
for  expressing  constraints  on  structures  as  found  in  IDL  and  in  RDL.  The  artide  concludes  with  a 
description  of  the  two  generation  environments. 

2  History 

The  IDL  technology  effort  originated  in  compiler  technology  and  grew  out  of  the  POCC  projed  at 
Camegie-Mellon  University.  One  component  of  this  technology  is  a  language  (referred  to  in  this 
article  as  IDL)  that  was  developed  as  a  generalized  data  definition  language  to  permit  interfadng 


of  results  from  different  project  components.  IDL  was  used  to  define  the  intermediate  represen¬ 
tation  for  Ada™  caHed  Diana  [3].  A  full  description  of  IDL  can  be  found  in  [13].  The  other  com¬ 
ponent  of  IDL  technology  Is  a  generation  tool.  Generation  of  software  based  on  an  IDL  descrip¬ 
tion  and  the  tool  supporting  the  generation  are  discussed  in  a  thesis  by  Lamb  [12].  More  recently, 
the  SoftLab  project  at  the  University  of  North  Carolina  has  been  building  a  Unix™/C-based  IDL 
generation  tool  [17]. 

Structure  editor  generation  technology  has  Ks  roots  in  syntax-directed  editors.  An  early  syntax- 
(firected  editor  system,  Emily  [9],  based  its  model  of  stmcture  manipulation  on  BNF.  Later  the 
Mentor  system  [4]  started  to  use  as  its  stmctural  representation  an  abstract  syntax  tree  represen¬ 
tation  —  as  was  dorte  in  Diana.  In  the  Aloe  system  [6]  of  the  GandaH  project  and  later  other 
structure  editor  systems  [10, 16],  structural  information  was  not  handcoded  into  the  system,  but 
descrbed  in  a  notation  with  many  similarities  to  IDL.  From  tfu^  description  an  implementation 
was  generated.  Structure  editors  provide  a  good  basis  for  interactive  applications  dealing  with 
structures.  Originally,  syntax-directed  editors  supported  incremental  program  oonstnjction,  i.e., 
programming  in  the  small.  Later  stnjcture  editor-based  environments  such  as  Gandalf,  a  com¬ 
plete  development  environment  [IS],  structure  edKor  generation  environments,  e.g.,  AloeGen 
[5]  and  Dose  [8],  and  non-programming  applications  [14, 7]  were  built. 

3  Architecture  For  Applications 

IDL  technology  assumes  that  an  application  reads  in  one  or  several  stmctures,  manipulates  them, 
and  then  writes  them  out.  For  that  purpose  the  IDL  generation  tool  produces  from  an  IDL 
description  reader  and  writer  routines,  structure  manipulation  routines,  njntime  support  routines 
(e.g.,  specialized  memory  allocation  routines),  and  constraint  checking  code.  Reader  and  writer 
routines  operate  both  with  an  external  ascii  representation  to  aid  portability  across  machine  ar¬ 
chitectures,  and  with  a  binary  representation  for  efficiency.  Stnjctures  that  are  read  or  written  can 
be  subsets  of  structures  maintained  within  the  application,  i.e.,  the  reader  and  writer  act  as  filters. 
An  appHcation  is  built  on  top  of  these  routines.  Constraint  checking  code  is  available  as  a 
separate  program  that  can  be  invoked  on  structures  that  are  read  or  written  by  applications.  An 
application  can  be  composed  of  one  or  more  IDL  processes.  An  IDL  process  represents  a  logicat 
processing  unit  that  takes  structures  as  input,  man^lates  them,  and  produces  stnictures  as 
output.  IDL  processes  are  interconnected  ^trough  their  input  and  output  stnjctures.  Several  IDL 
processes  can  be  mapped  into  one  application  program.  In  this  case  reader  and  writer  routines 
act  as  filters  for  in-oore  stnjctures.  The  left  diagram  of  Figure  1  illustrates  such  an  IDL-based 
application  architecture. 

Structure  editor  generation  technology  supports  the  oonstnjction  of  application  for  interactive 
manipulation  of  stnjctures.  Such  applications  are  created  from  an  interactive  stnxmjre  manipula¬ 
tion  shell  that  is  provided  by  the  generation  system.  The  shell  consists  of  two  layers.  This  is 
llustrated  for  the  Dose  environment  in  the  right  diagram  of  Figure  1 ,  yet  applies  to  other  stmcture 
editor  systems  as  wel.  The  lower  layer  of  the  shell  corresponds  to  the  generated  IDL  routines, 
i.e.,  it  consists  of  reader  and  writer  routines,  stnjcture  manipulation  routines,  and  nintime  routines 
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ngura  1 :  Comparison  of  IDL  and  RDL  Application  ArchRedures 

such  as  specialized  memory  management.  Readers  and  wrRers  work  according  to  views,  i.e., 
they  can  read  and  write  substructures  and  as  a  resuR  act  as  fflters  for  passing  stmctures  between 
dVferent  instances  of  stnjcture  edRor  sheRs.  This  layer  of  the  shefl  is  complemented  wRh  a 
second  layer  that  provides  fadHties  for  interadive  manipulation  of  the  stnidures  and  for  triggering 
oonstraM  checking  and  application-spedfic  processing.  The  Meradive  fadIRies  include  a 
window-  and  menu-based  user  interface,  a  command  Interpreter  wRh  on-line  help  support,  and 
capabilRies  for  viewing,  browsing,  and  modKyRtg  strudures.  MuRiple  views,  both  textual  and 
graphical  [7],  are  supported.  Display  of  views  is  generated  at  njniime  on  demand,  i.e.,  only  for  the 
part  of  the  stnjcture  the  user  actually  desires  to  examine.  Views  permR  the  user  as  weH  as 
application  code  to  interad  with  a  subset  of  the  stnidure.  MuRiple  views  providing  access  to 
dRfereni  levels  of  detail  in  the  stnjcture  effectively  provide  browsing  fadIRies.  The  trigger  fadlity 
of  the  shefl  is  adivated  whenever  the  user  manipulates  a  part  of  the  stnjcture.  A  symbol  process¬ 
ing  mechanism  is  invoked  when  an  UerRRier  is  entered,  touched,  or  removed  in  the  stmcture. 
ConstrairR  checking  routines  and  application  processing  routines  are  invoked  both  on  movement 
of  the  edRor  cursor  and  on  manipulation  operations.  Triggering  at  small  granularity  permRs  in¬ 
cremental  checking  and  processing,  resuRing  in  an  interadive  application. 


4  Structural  Description 


The  stnjdural  description  spedfies  stnjdures  in  terms  of  typed,  attributed,  direded  graphs. 
Produdions  define  node  types,  and  the  names  and  types  of  their  attributes. 


IDL  suppc  the  following  primitive  types;  boolean,  integer,  rational,  and  string.  Other  types  are 
defined  through  oomposRion.  IDL  supports  sets,  sequences,  user  supplied  type  declarations,  and 
classes.  Sets  and  sequences  can  be  applied  to  any  attribute.  They  can  be  empty.  User  defined 
type  declarations  refer  to  types  that  are  implemented  in  separate  packages.  This  permRs  new 
types  to  be  introduced  and  different  implementations  for  existing  types  to  be  given,  e.g., 
representation  of  an  integer  wRh  range  1..100  as  a  byte.  Classes  define  unions  of  node  types. 
IDL  supports  a  non-Nerarchical  class  stnjcture.  Enumerattons  can  be  expressed  as  classes  of 
produdions  wRh  no  attributes  for  the  productions. 


In  RDL  the  pr).nitive  types  are  integer,  string,  and  identifier.  In  the  latter  case  definition  and  use  of 
identifiers  are  distinguished.  This  simplifies  the  mechanisms  for  symbol  processing.  Composition 
facilities  include  enumerated  types,  class,  sequence,  and  optionaiity.  Different  from  IDL, 
enumeration  is  represented  explicitly,  permitting  the  generation  system  to  optimize  its  represen¬ 
tation.  Boolean  is  defined  as  an  enumerated  type.  In  RDL  a  class  definition  consists  of  a  list  of 
production  names.  Sequences  apply  to  any  attribute  and  are  expected  to  have  one  or  more 
elements.  Optionaiity  indicates  whether  an  attrS)ute  is  required  or  not.  This  results  in  cardinality 
restrictions  on  attribute  values  ( attribute  ->  1;  optional  attribute  ->  0  or  1 ;  sequence  ->  1  or  more; 
optional  sequence  •>  0  or  more).  Sets  were  not  felt  to  be  necessary.  Instead,  the  notion  of 
symbols  (identifiers)  and  associated  name  and  symbol  tables  are  explicit  in  stnjcture  editors. 

5  Structure  Composition  and  Views 

IDL  and  stmcture  editor  generation  technology  take  different  approaches  to  dealing  with  structure 
composition  and  views  on  structures.  IDL  t2d<es  a  process-oriented  view  of  the  application 
whereas  structure  editor  generators  take  a  data  base/objeci  base-oriented  view. 

In  IDL,  structures  are  specified  with  structure  declarations.  Structure  declarations  consist  of  a  set 
of  productions  and  classes,  and  a  reference  to  the  type  of  the  stnjcture  root.  Stnjctures  can  be 
refined  or  derived  from  other  structures.  Refinement  allows  the  specification  of  a  more  detailed 
representation  of  the  old  structure.  Derivation  permits  the  specKication  of  a  new  stnjcture  by 
indication  of  differences  with  another  stnjcture  —  a  convenience  for  dealing  with  several  simitar 
stnjctures.  An  IDL  process  is  composed  of  input  and  output  structures  as  well  as  stnjctures  that 
are  maintained  within  an  application. 

In  RDL,  a  structure  is  specified  in  a  representation  description  (RD)  through  a  set  of  productions 
and  classes,  and  a  stnjcture  root.  This  stnjcture  is  decomposed  into  substnjctures.  Substnjc- 
tures  are  specified  by  defining  views  on  the  structure.  A  view  specification  is  attached  to  each 
prochjction.  It  indicates  a  subset  of  the  node  types  and  attributes  that  are  accessible.  They  can  be 
accessible  with  modification  rights  or  read-only.  Views  are  augmented  with  templates  for  genera¬ 
tion  of  displayable  representations.  The  same  template  information  can  be  used  to  generate 
parsers.  A  set  of  views  showing  a  stnjcture  at  different  levels  of  detail  provide  the  basis  of  a 
structure  browsing  facility.  Conditional  views  allow  queries  to  be  specified  on  structures.  Ex¬ 
amples  of  queries  that  can  be  defined  through  views  are  Vhet  are  all  the  procedures”  or  "which 
modules  still  contain  errors.”  A  more  extensive  discussion  of  the  power  of  stnjcture  editors  as 
structure  viewed  can  be  found  in  [7]. 

In  RDL,  an  application  can  make  use  of  multiple  representation  descriptions.  The  specification  of 
an  attrixjte  in  one  RD  can  refer  to  a  class  in  another  RD.  This  permits  partitioning  of  represen¬ 
tation  descriptions,  which  is  desirable  for  applications  with  large  stnjctures  such  as  development 
environments  (see  for  example  the  Gandaif  system  [15]).  This  partitioning  of  the  RD  implies  that 
structures  based  on  these  descriptions  are  managed  accordingly.  Each  stnjcture  partition  can  be 
stored  to  and  loaded  from  secondary  storage  as  a  separate  unit.  Multiple  representation  descrip- 


tions  are  managed  by  the  generation  environnient  DOSE  rather  than  through  additional  language 
constructs. 

6  Constraints  and  Processing 

IDL  supports  the  specification  of  assertions  on  stmctures.  The  assertion  language  has  constructs 
for  conveniently  dealing  with  graph  structures,  sets,  and  sequences.  Assertions  are  expected  to 
hold  when  a  structure  enters  and  leaves  an  IDL  process.  No  constraints  are  implied  while  the 
process  is  manipulating  the  structure.  In  the  SoftLab  implementation  assertions  are  translated 
into  a  checker  program  that  can  be  invoked  on  a  structure  it  has  written  or  read  before,  if  not 
translated  into  checking  code  assertions  still  act  as  specifications  in  that  they  document  con¬ 
straints  on  the  stnjcture  that  the  application  is  expected  to  adhere  to  at  certain  times. 

Structure  editors  emphasize  interactive  manipulation  of  stmctures  and  incremental  processing. 
For  that  purpose  two  triggering  mechanisms  are  provided  with  stmcture  editors:  an  action  routine 
mechanism,  and  a  symbol  processing  mechanism. 

The  action  routine  mechanism  activates  actions  as  the  stmcture  is  manipulated  or  traversed,  e  g., 
by  editing  or  cursor  motion  commands.  Constraints  and  application  processing  are  associated 
with  node  types,  and  are  activated  when  a  node  of  that  particular  type  is  operated  on.  Con¬ 
straints  and  application  processing  are  expressed  in  a  high-level  procedural  language  with  sup¬ 
port  for  traversal  and  manipulation  of  graph  stmctures  and  sequences.  It  supports  the  description 
of  both  checking  and  processing.  Static  semantic  checking  as  well  as  additions  and  chartges  to 
the  stmcture,  for  example  derivation  of  a  procedure  call  template  with  actual  parameters  from  its 
specification,  can  be  expressed.  In  order  to  fully  support  application  code  an  escape  into  an 
underlying  programming  language  is  provided  where  necessary.  Efforts  on  other  stmcture  editor 
generation  systems  have  resulted  in  incremental  attribute  grammars  [2],  and  in  active  constraints 
[11]  as  constraint  languages. 

The  symbol  processing  mechanism  activated  routines  for  handling  definitions  and  uses  of  iden¬ 
tifiers.  It  is  triggered  by  operations  on  instances  of  the  primitive  types  identifier-definition  and 
identifier-use.  The  generation  environment  supplies  a  default  implementation  for  symbol  process¬ 
ing,  which  can  be  augmented  by  the  user  of  the  generation  environment.  The  user  does  so  by 
supplying  a  description  of  the  new  symbol  table  stmcture  using  the  stmcture  description  language 
as  well  as  of  the  necessary  processing  in  terms  of  the  graph-oriented  processing  language. 

7  Generation  Environment 

The  generation  environment  for  IDL  consists  of  your  favorite  text  editor  for  developing  IDL 
descriptions,  an  IDL  translator  that  processes  IDL  descriptions,  an  IDL  Ibrary  that  contains  stmc¬ 
ture  description  independent  IDL  routines  and  is  linked  in  with  the  generated  routines  and  the 
application  code,  and  some  debugging  tools.  Compilation  and  linking  is  done  with  application 
language  tools.  The  SoftLab  implementation  of  the  IDL  translator  maps  structural  information 
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directly  into  the  application  language,  taking  advantage  of  its  structural  constructs  and  type 
mechanistns.  Lamb's  translator  chose  a  table-driven  implementation  lor  the  generated  code.  It 
has  been  realized  that  changes  in  the  structure  can  require  massive  recompilation  of  the  applica¬ 
tion  [1].  Therefore,  both  an  efficient  production  implementation  and  a  more  flexible  development 
implementation  have  been  proposed.  Two  debugging  tools  are  provided  with  the  SoftLab  im¬ 
plementation.  One  program  graphically  plots  externally  stored  IDL  structures.  A  second  program 
generates  cross-reference  information  for  stmctures. 

The  most  obvious  generation  environment  for  structure  editors  is  similar  to  that  of  IDL.  On  several 
occasions,  however,  the  generation  environment  has  been  built  as  an  instance  of  a  structure 
editor  based  interactive  application.  Both  AloeGen  and  Dose  are  good  examples.  The  formal 
notation  of  structure  descriptions  is  described  in  itself  resulting  in  an  instance  of  a  structure  editor 
shell  for  structure  descriptions.  These  interactive  generation  environments  take  full  advantage  of 
the  capabilities  provided  by  the  structure  editor  shell.  Users  can  stmcturally  manipulate  descrip¬ 
tions.  Users  can  develop  the  structural  description,  the  constraints  and  application  actions,  and 
auxiliary  stmctures  in  the  same  environment.  Multiple  views  provide  browsing  and  querying 
facilities,  reducing  the  amount  of  information  seen  at  any  one  time.  Through  these  views  the  user 
can  examine  structures  and  cross-reference  information  interactively.  The  description  is  checked 
for  constraint  violation  interactively  as  the  description  is  being  developed  (i.e.,  the  description  of 
the  formal  notation  includes  constraints  and  processing). 

AloeGen  takes  a  table-driven  approach  for  the  implementation.  The  generated  »ystem  consists 
of  a  structure  independent  pari  and  a  stmcture  dependent  part.  The  structure  independent  part  is 
a  shell  or  kernel  consisting  of  the  manipulation  routines,  reader  and  writer,  user  interface,  and 
command  interpreter.  The  stmcture  dependent  part  consists  of  a  table  containing  the  stmctural 
information,  anti  a  collection  of  routines  representing  the  constraints  and  the  application  actions. 
A  new  instance  of  a  structure  editor  application  is  created  by  linking  the  kernel  code  with  the 
constraint  and  application  routines  and  linking  in  or  dynamically  reading  in  the  table.  AloeGen 
accomplishes  the  translation  of  a  structural  description  or  a  constraint  description  through  muKiple 
textual  views.  One  view  of  the  description  is  that  of  the  description  notation  or  constraint  ian- 
guage,  whereas  a  second  view  transforms  the  description  into  C  code  representing  the  table  and 
the  checking  and  processing  routines,  i.e.,  the  stmcture  editor  is  not  only  a  tool  for  developing 
descriptions,  but  also  acts  as  the  generation  tool. 

Dose  takes  a  different  approach.  Stmctural  information  and  constraint  descriptions  are  created 
by  the  :  mcture  editor  as  a  stmcture.  This  stmcture  represents  the  stmcture  dependent  part  of 
the  system.  This  structure  is  directly  interpreted  by  the  stmcture  editor  kernel,  i.e.,  the  Dose 
stmcture  editor  system  does  not  require  a  translation  or  generation  step.  The  stmcture 
representing  a  structure  description  or  constraint  description  is  read  into  the  editor  and  accessed 
using  the  same  kernel  facilities  that  are  used  to  deal  with  the  application  structure.  The  structure 
editor  does  so  by  interpreting  a  description  for  stmcture  descriptions,  which  is  represented  as  a 
structure  in  turn.  Fig.  2  gives  a  structural  description  of  an  RDL  production  described  in  RDL. 
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pxodnam*  :  Idontdof, 
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<eoiBpon«nts*>  [',8n']  ':%<') 

(fulljvlow) : : 

Figure  2:  Description  of  a  Production  in  RDL 
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The  direct  interpretation  of  stmcture  descriptions  turns  Dose  into  a  prototyping  environment  for 
description  and  language  development.  The  user  of  the  Dose  generation  environment  can  inter¬ 
actively  switch  between  working  on  the  description  and  testing  it  by  creating  structures  based  on 
the  description.  A  screen  snapshot  of  the  Dose  generation  environment,  showing  a  window  with  a 
Pascal  structure  description,  a  wirKfow  with  an  application  processing  routine,  and  a  window 
displaying  an  instance  of  the  discribed  stmcture,  i.e.,  a  Pascal  program,  is  provided  in  Figure  3. 

8  Conclusions 

The  comparison  of  IDL  and  structure  editor  generation  technology  are  summarized  in  Fig.  4. 
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RDLyDose 

Application 

Architecture 

stmcture  manipulation  and 
read/Write  primitives 
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applications 
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Generated  Code 
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Toois/Environments 
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processing  tools 
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interactive  environment 

Figure  4:  Summary  of  Comparison  of  IDL  and  Structure  Editors 


IDL  technology  and  structure  editor  generation  technology  have  their  separate  origins  and  were 
developed  to  address  different  application  domains.  They  both  have  addressed  the  issue  of  more 
effectively  building  software  that  operates  on  stmctures  (typed  object  bases).  Formal  high-level 
descriptions  specify  the  structure  and  constraints.  These  descriptions  can  be  translated  into  a 
variety  of  (quite  efficient)  implementations.  The  differences  come  in  because  IDL  was  targeted  to 
support  tool  intercommunication,  whereas  with  structure  editors  the  emphasis  was  in  providing  a 
shell  for  building  highly  interactive  applications. 

Both  technologies  can  profit  from  each  other.  IDL  can  benefit  from  an  interactive  generation 
environment  based  on  a  structure  editor.  It  can  also  incorporate  into  its  generation  process  dif¬ 
ferent  flexble  implementation  techniques  and  additional  support  routines,  especially  in  supporting 
the  development  of  interactive  applications.  Structure  editor  generation  technology  can  take  ad¬ 
vantage  of  the  inplementations  generated  by  IDL  tools  for  the  implementation  of  structure 
editors.  The  result  could  be  very  time  and  space  efficient  stmcture  editor  implementations. 
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